仙台勉強会「Tohoku.Tech #1 Hello, world!」を開催しました！AI搭載エディタを使った開発 | ECサイト開発事情 | GPTの活用

クラスメソッド仙台オフィスが開設されました。仙台でIT勉強会を継続的にやっていきます第1段です。ヘッドレスコマースとは？からChatGPTを使ったAWS構築と検証、そしてAI搭載エディタを使った組み込み開発まで幅広な話題でした。多数の参加者にお越しいただき、とても盛り上がりました。

#ChatGPT

千葉淳

2024.03.18

コンニチハ、東北出身の千葉です。

クラスメソッド仙台オフィスが開設されました。東北出身の私の血が騒ぎます。東北を中心とした勉強会コミュニティを立ち上げなければという使命感が止まりません。定めです。運命です。天命です。

ということで、Tohoku.Tech #1 Hello, world! を開催しました。このブログでは、勉強会のレポートをお届けします。

ヘッドレスコマースとは？からChatGPTを使ったAWS構築と検証、そしてAI搭載エディタを使った組み込み開発まで幅広な話題でした。多数の参加者にお越しいただき、とても盛り上がりました。今後も定期的な開催を目指しています。いろいろな方に登壇いただき、みんなの知見が広がる場所にしていきたいです。

Tohoku.Tech はテンダさんと企画し開催しました。またテンダさん支援の下、WeWork JR 仙台イーストゲートビル共有エリアにて開催しました。

それでは勉強会レポートをお届けします。

EC-CUBE/AWSの構築をChatGPTに相談してみました

登壇者：株式会社テンダ　島田裕基

調査に検索エンジンを使わずChatGPTのみを使って、AWS上にEC-CUBEを構築してみた話でした。EC-CUBEはECサイトを構築する日本の製品です。今回はChatGPT-3.5がどこまで知識を持っていて構築対応できそうかという検証でした。対話ですべて構築を目指しましたが、エラーなどの深い部分は一部インターネット検索によるが必要になりましたが、8割はChatGPTを使って構築できました。ChatGPT-4やClaude3を使うとまた違う結果になったかもですね。

Cursorを使ったRaspberry Piの開発

登壇者：株式会社ねこまた　齋藤昌秀

会社名「ねこまた」の語源は、Network Computing with Machines and Tablets。年齢を重ねてもプログラマが活躍できる場所を作りたいと思い起業したとのことでした。IT業界の町工場のような会社。PoCが得意で、最近は医療機器を制御するステッピングモーターを制御する仕事にチャレンジしており、そこで Cursor を使って効率よく開発したお話でした。Cursor は VSCodeのフォーク版で、The AI-First CodeEditor を目指したAI搭載エディタです。ラズパイでLEDを光らすなどハードウェアの制御開発をCursor を使い実装。ハードウェアの仕様などドメイン知識は、Cursor 側で補完できる場面を多く、コード自体の解説もしてくれてかなり仕事に役立ったとのことでした。実際開発に使ってみてAIによって人が不要になるか？というところの考察も興味深かったです。

EC 基盤「ヘッドレスコマース」やってみた

登壇者：クラスメソッド株式会社　今野壮輝

マイクロサービスの考え方を取り入れたECサイトのアーキテクチャ。モノリシックな構成ではなく、フロントとバックエンドを分離することでセキュアでパフォーマンス、スケーラビリティを獲得ができるというお話でした。またバックエンド1つで、フロントをWebだったり、モバイルだったり店舗端末だったり柔軟な構成がとれる、ブランドデザインの反映も反映しやすくなる。フロントとバックエンドを分離することで疎結合化のメリットが得られるなる構成になるとのことでした。反面マイクロサービス化することで生まれる責任境界の曖昧さやによる開発の難しさ、トラブルシューティングの難易度があがったり、開発面運用面で乗り越えないと難しさも発生するため新しい考慮ポイントの示唆もありました。またバックエンドとフロントエンドの中間にBFF(backend for frontend)設けることによる、共通化できない業務ロジックに対応する層を設けることで柔軟な対応もできるとのことでした。

ヘッドレスコマースとは？
- フロントエンドとバックエンドを別々に管理
- 例えばヘッドレスCMSなど
- ヘッドレスのヘッド=フロント
- 分離することでフロントの変更がやりやすい=ブランドを反映したデザインを作りやすい
- モバイル、Web、店舗機器など、フロントのチャネルを変えてもバックエンドは1つにできる
- セキュリティやパフォーマンス、スケーラビリティがあり大規模な要件にも対応しやすい
どう作る？
- BFF：バックエンドとフロントの中間のシステム、汎用以外の独自ロジックを吸収するティア
ここが難しい！
- 全部APIをベースとしたやりとり：実際やってみるとAPIでしかやりとりできないのは大変。フロントもDB直じゃなくて、API通じてやるのでデータの整合性を保つためのエラーハンドリングが難しい。リカバリもAPIの分だけ検討が必要。
- 責任分界点：どの機能をフロント、BFF、バックエンドかを明確にしないとテストフェーズで判明するケースやトラブルシューティングが難しい
- 関連システムが多くなり複雑さが増える
- フロントの種類が多くなる、チャネル分BFF、データベース、データ連携が必要になる